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(57) Abstract: Systems, methods and computer readable 
media for enabling a server device (5) to validate one or 
more client devices (1). A shared unpredictable secret 
(50) is generated. The shared unpredictable secret (50) is 
stored in the client device (1) and in die server device (5). 
The client device (1) proves possession of a correct shared 
unpredictable secret (50) to the server device (5). The 
shared unpredictable secret (50) is replaced by a new shared 
unpredictable secret (54) each dme the client device (1) is 
validated by the server device (5). 
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These and other more detailed and specific objects and 
features of .the present invention are- more fully disclosed in 
the following specification, reference being had to the . . . 
accon^suaying drawings, in which: 
.5 Figure 1 is a block system- level diagram of a. preferred • 

embodiment of the present- invention. 

Figure 2 is a flow diagram of a preferred embodiment of. 
the registration/reset phase of the present invention. 

Figure 3 is a flow diagram of a preferred embodiment of. 
.10 the log- in phase of the present invention. 

Figure 4 is a flow diagram illustrating an alternative 
embodiment of the method illustrated in Figure 3. 

Figure .5 is an illustration of shared unpredictable secret 

50 and its progeny. 

15 Detailed Peaerit>tion ot the Preferred Bnbodiinente 

AS used in the present patent application, client 
(sometimes referred to as -client device") 1 can be any digital 
device, e.g., a personal computer, mobile phone, smartcard, 
internet appliance, or any other netjjork accessible device. 

20 . There may be one client' V"or, as illustrated in Figure 1, a 
finite number n of clients 1. Each client 1 wishes to 
communicate with. an inf rastructural component that is referred 
to in the present patent application as a server (or "server 
device") 5. server 5 may provide any type of .^service to.^client 

25 1. For example, server^ 5 might be an Internet service provider 
. or a telephone network access point. The communications link 
between client 1 and server 5 may be any link, such as a 
wireless link, a wired link, or a link over a network 4, which 
may be an open network such as the internet. The process that 

30 commences with client 1 requesting validation with server S and 
including server 5. checking proof data that client 1 has- 
generated from the shared unpredictable secret 50 is referred 
to herein as a "log-in" . A log-in results in client 1 being 
either validated or not validated by seirver 5. . 
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Degcrlption 
COUNTERXNO CRKD&m:XALS COPYING 

Inventor: Warwick Ford 

Related Application This patent application is related to and 
5 claims priority from U.S. provisional patent application serial 
no, 60/226,429 filed on August 18, 2000, entitled "Coxintering 
Credentials Theft", having the same inventor and assignee as 
the pr*esent patent application. 

Technical Pield This invention pertains to the field of 
10 authenticated comm\ini cat ions between and among digital devices 
such as computers, and, specifically, pertains to techniques 
for thwarting the copying of credentials by nefarious persons 
or otherwise. 
Backgrotmd Art 

IS Diff ie-HellTiian key exchange, as described in U.S. patent 

4,200/770, is a mechanism to permit two entities to have a 
shared secret.; the secret could be an encryption key. In the 
present invention, shared unpredictable secret 50 is not an 
encryption key. 

20 Disclosure of Invention 

The present invention comprises systems, methods, and 
cott^uter readable media for authenticating a client device (1) 
to a server device (5) . A preferred method comprises the steps 
of generating a shared unpredictable secret (50), storing the 

25 shared oinpredictable secret (50) in the client device (l) and 
in the server device (5), and requiring the client device (1) 
to prove that it contains the correct . shared unpredictable 
secret (50). as a precondition to the server device (5) 
validating the client device (1). The. shared unpredictable 
30 secret (50) is replaced by a new shared impredic table secret 
(54) each time the server device (5) validates the. client 
device (1) • . 

Brief Description of the Drawings 
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one concern in such an environment pertains to credentials 
sharing. In this scenario, a person who has access to a client 
device 1 voluntarily shares his personal credentials, such as a 
password or private cryptographic key, with other user devices 
2 . All of these user devices 2 employ the user account of the 
original user. Two problems that arise from this scenario are: 
1) It is difficult for server 5 to hold particular users 2 
accountable for their actions when using the services provided 
by server 5, since some or all users 2 are indistinguishable 
from each other; and 2) Users may fraudulently avoid paying 
subscription fees that are designed for payment on a per-user 
basis . 

Another concern is outright credentials theft. In this 
scenario, a nefarious person having access, to a client-like 
device, referred to as "attacker 3" in Figure 1, penetrates a 
legitimate client device 1, copies stored credentials data from 
client device 1 into attacker device 3, perhaps supplements 
this thievery with a determination of other information such as 
the user's password, personal identification number, or social 
security number from other sources, and then masquerades as the 
legitimate user from the attacker device 3. When the client 
device 1 being attacked is a hardware device and not a software 
■= module, this scenario is sometimes referred to as "device 

cloning" . Client devices 1 that are typically cloned include • 
25 mobile telephones and smartcards. 

The present invention also applies to the copying of a 
portable credentials storage medium such, as a magnetic stripe 
card or ticket if that medium is writable as well as readable 
by the terminal device in which it is used. In this case, the 
term client, device 1 is taken to mean the combination of the 
portable credentials storage medium and the terminal device in 
which it is currently inserted. 

The present invention uses a method of stateful 
authenticators to provide a low cost, low overhead means of. • 
35 detecting when one user account is being -employed for more than 

3 
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one client device 1 over a period of time. Specif ically-/ the h 
stateful authenticator used herein is a shared unpredictable 
secret 50.. The present invention has utility in countering 
credentials sharing behavior by effectively restricting use of 
5 a user account to one or a limited nuniber of client , devices 1. 
The invention also counters credentials theft by mecuis of 
detecting the use of one user account from more than oiie client 
device 1 after stored credentials have been copied between \, 
client devices 1, regardless of how easy or difficult it was to 

10 copy the credentials from the original device 1. 

All of the method steps illustrated herein describe 
modules that can be implemented in hardware, software, and/ or 
firmware. Some of these modules reside on the client device 1. 
and some on the server device 5/ as will be readily understood 

15 by examining the Figures in conjunction with the following 
description. 

The method will first be described with respect to a 
special case in which there is but one legitimate client device 
1. There are two phases of the method of the present 

20 invention: a registration/reset phase and a log-in phase. 

Figure 2 illustrates the registration/reset phase. In 
step 21, . client 1 typically presents a user's authentication 
data to server 5i The ensuing dialog between client 1 and 
server S is geared to determining whether the user associated 

25 with client 1 is legitimately associated with a claimed user 
account . The authentication data presented by client 1 may 
include private personal data, a response to a pre-established 
challenge question posed by server 5, . a biometric input such as 
a fingerprint or an eyeball scan, etc. Alternatively, the 

30 registration/reset phase may involve the user making a payment; 
in which case authentication data may or may not need to be 
presented by client 1 to server 5. The payment can be made by 
client 1 secxirely crediting server 5's account, and can be made 
online or offline. The registration/reset phase is typically 

35 undertaken less frequently than the log- in phase. 
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At Step 22, server 5 decides whether the authentication 
data presented by client 1 are acceptable. If not, client 1 is 
not allowed to register ..(step 26) . If acceptable, client 1, is 
allowed to register (step 23) . In this eventuality, the shared 
unpredictable secret SO is generated (step 2.4) . 

As illustrated" in. Figure 5, the shared unpredictable 
secret (SUS) 50 comprises an unpredictable component 51 and .an 
optional fixed cotnponent 52 . Unpredictable component 51 may be 
generated by a random number generator or a pseudo-random . 
number generator. Typically, unpredictable component SI is 
h generated at server 5 and communicated to client 1, but it may 
also be generated at client 1, or at a combination of server 5 
. and client 1. As an alternative to communicating unpredictable 

component 51 to client 1, unpredictable component 51 maybe 
15 pre-ins tailed in client device 1 during manufacture or during a 
device 1 personalization process . 

When used, fixed component 52 typically comprises 
identification information. For example, fixed component 52 
may be a serial number of the client device 1. This could be 
useful when there are two or more client devices 1 associated 
with the same user account number. Conversely, fixed component 
52 could be the user account number when there is more than one 
user account number associated with the same client device 1 . 
This situation may occur, for example, when a user has one 
25 account number for business use and another account number for 
• personal use; or when tU users share the same cellular 

telephone 1; or when the client device 1, is a terminal into 
which users insert their credentials storage media. 

Typically, after server 5 has generated SUS 50, server 5 
transmits SUS 50 to client 1. The transmission is preferably 
encrypted, for reasons of security. Any type of encryption, 
including symmetric or asymmetric encryption, may be used. 
Alternatively, an SUS 50 having an unpredictable component SI 
is generated by the aforementioned Dif f ie-Hellman key exchange 
technique, or pre -installed in device 1 as described 
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previously. The same SUS 50 is stored in both server 5 and 
client 1 (step 25) • . SUS 's 50 may be stored in a .secure 
fashion, such as using tamper-resistant hardware protection, 
e.g., epoxied integrated circuits, or by means of dynamically 
5 chamging the location of SUS's 50 (and new SUS's 54) in 
storage • 

Figure 3 illustrates the basic method of the log-in phase. 
The log-in, at least for legitimate users, is not meant to be 
attempted until after the registration/ reset phase has 
10 successfully concluded. Steps 30, 31, and 32 are optional. At 
step 30, client 1 presents credentials to server 5. The 
credentials may include a password, personal identification 
nxamber (PIN), a transformed (e.g. hashed) password, biometric 
signature, portable credentials medium identifier, or 

15 cryptographic authentication proof generated from a private 
cryptographic key. Since log- ins normally occur more 
frequently than registration/resets, the character and content 
of the credentials and procedure are such that the server's 
check of the credentials is typically simpler and faster than 

20 the a&xvBx^e check of the user's authentication data in 

previoxisly-described step 21. In step 31, server 5 checks the 
credentials. If the check fails, typically the client is not 
validated (step 32) . 

If. step 32 is entered, one or more things may happen. For 

25 example, client 1 may be totally rejected and not allowed to be 
validated ever again. Less onerously, client 1 could be given 
reduced privileges, such as the ability to read a Web page 
stored on server 5 but not to conduct any financial 
transactions thereon; or client 1 could be made to re-enter the 

30 registration/ reset phase . 

If the check passes, the method moves to step 33, where . 
client 1 presents proof data to server 5. The proof data 
allows server 5 .to verify that client 1 holds a correct - secret 
50, 54. (Normally, the secret is SUS 50. However, the secret^ 

35 could be new SUS 54, in the case where the log- in is a 
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subsequent log-in following the re-set of server 5 as described 
in conjunction with step 43, below.. .For purposes of 
sin^lifying this discussion, it will be assumed that the proof 
data are computed upon SUS 50.) It is desirable that SUS 50 
itself be not directly communicated over an open network 4 lest 
it be intercepted by a nefarious person. One method by which 
client 1 computes proof data without revealing SUS 50 itself is 
for client 1 to compute a one-way function of SUS SO. The one- 
way function is typically a cryptographic hash function. Then, 
at step 34, server 5 checks the proof data by applying its 
(server B's) proof data generation algorithm to its (server 
5's) stored version of SUS 50. If the proof data, generated by 
server 5 matches the proof data presented by client l, client 1 
has passed the test, and. the method proceeds to step 37. 
Otherwise, client 1 has failed the test and is not validated at 
step 32. Step 32 operates as previously described. 

in order for this method to work, client 1 and server 5 
have to be using consistent if not identical proof data 
generation algorithms. It is immaterial whether or not an 
eavesdropper knows what this algorithm is (or what these 

algorithms are) . 

At Step 37, update data 53 and a new shared unpredictable 

secret 54 are generated, typically by sever 5. On Pig. 3 
(boxes 37 and 39) , item 54 is referred to as a "secret". rather 
than a "shared unpredictable secret", because the contents of . 
the storage area that server 5 uses for SUS's are not replaced 
with new SUS 54 until step 40 is executed, below. Thus,, the 
secret is not yet "shared". 

Then, at step 38, server 5 sends update data 53 to client 
30 1. update data 53 is such that client 1 and server 5 are able 
to generate new SUS 54 from the most recent version of SUS 50, 
by means of applying update data 53 thereto. Typically, the 
step of applying update data 53 to SUS 50 con^rises computing ^ 
one-way function of the combination of SUS 50 and update data 
53. For example, update data 53 could be a new random or 
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pseudo-random nximber that client 1 and server 5 XOR with old 
SUS 50 in order to generate new SUS 54, Alternative to the use 
of update data S3, server 5 could send an encrypted new SUS 54 
to client 1, but the advantage of sending update data 53 is 
5 that update data 53 do not have to be encrypted, thus making 
for a simpler and less cumbersome protocol. In an alternative 
embodiment, in situations where the optional acknowledgement 
data are used (see below) , server 5 sends to client 1 an old 
SUS 50 that hasn't been acknowledged yet . 
10 At step 39, client 1 updates its (client l*s} storage area 

that is allocated to SUS's with new secret 54. Client I's 
storage area may be on a portable credentials storage medium. 

Steps 41/ 42, and 43 are optional. Without these steps, 
the method illustrated in Figure 3 works well when the 
IS communications channel 4 is clean and uncorrupted, but a 

potential problem arises in the case of a noisy or corrupted 
channel 4: update data 53 could be lost in transit between 
client 5 and server 1, or client 1 could fail to correctly 
store new secret 54. 
20 The inclusion of steps 41,. 42, and 43 resolves the problem 

of noisy or corrupted chsmnels 4 or a malfvmctioning client 
device 1, through the use of acknowledgement (ACK) data. In 
step 41, client 1 sends the ACK to server 5 after client 1 has 
successfully received update data 53 and stored the new secret 
25 54. The ACK may optionally contain proof data allowing server 
5 to verify that client 1 has successfully computed the new SUS 
54. The proof data should not be the same proof data as used 
in step 33/ otherwise, a replay attack would be possible. 

At step 43, server 5 is set (e.g., programmed) to accept 
30 proof data emanating from any SUS's since the previous 

validation, plus new SUS 54. Another way of saying this is 
that server 5 is adapted to accept from client i any proof data 
that axe generated from a secret that is newer than the secret 
for which the most recent acJaiowledgement data have been 
35 received by server 5. Thus, if the situation is that client 1 
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has received the update data 53, but for some reason- the ACK 
has been lost in transit, during, the next log- in, client 1 at 
step 33 will be presenting proof data emanating from new SUS 
54, and server 5 at step 34 will be programmed to accept said 
data. If, on the other hand, update data 53. were not received 
by client 1, then, during the next log-in, client 1 at step 33 
will be presenting proof data emanating from an old SUS 50, and 
server 5 at step 34 will be programmed to accept said data. 

Step 42 illustrates the reality that server 5 may or may 
not receive the ACK, either because the update data 53 were 
lost in transit, the ACK was lost in transit, or the client 
device 1 failed. If server 5 receives the ACK within a 
preselected "time-out" period, then client 1 is validated at 
etep 44 and step 40 is entered into. At step 40, server 5 
updates its (server 5's) storage area that is allocated to 
SUS's with new secret 54. Thus, new secret 54 becomes a new • 
shared unpredictable secret, because it is now shared by client 
1 and server 5. As a substep to step 40, server 5 deletes SUS 
SO and any older SUS's from its list of acceptable SUS's. 
Thus, in future log-in attempts, both client 1 and server 5 
will . have stored therewithin new SUS 54; and the proof data (of 
client 1 in step 33 and server 5 in step 34) will be based upon 
new SUS 54. 

If, on the other hand, server 5 does not receive at step 
42 the ACK from client 1 during the time-out period, client 1 
is not validated at step 32, which executes as described 
previously. 

The protocols described herein have the following 
desirable properties: 1) Any SUS (SO) value produces no more 
1 than one validation; and 2) If the protocol fails at any stage, 
both client 1 and server 5 are left in a state that a new 
invocation of the protocol will operate correctly. 

optionally, for example in conjunction with step 34, 
server 5 maintains an audit trail -of log-in attempts, noting in 
; particular those log- in attempts in which the step 34 checks 
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have failed. Each audit record should contain the then- current 
values of old SUS 50 and new SUS 54. In the event a legitimate 
user disputes accountability for actions attributed to use of 
his account, if ser-ver 5 maintains an audit trail of log-in 
5 atten^ts, the service provider or systems administrator can use 
the audit trail in resolving such disputes. h. 

By using the techniques described herein, any user 
possessing or knowing correct credentials and attempting a log- 
in. from a client device 1 that holds the correct SUS 50 will 
10 succeed in being validated, even in the event a log-in sequence 
is not successfully coir^^leted, owing, for example, to a 
communicatioh or system failure. 

The present invention automatically protects against 
message replay, i.e., the situation where an eavesdropper 
15 records a session and plays it back. This is because a new SUS 
54 is generated at each successful validation. 

If the legitimate user of the credentials voluntarily 
• shares his credentials with one or more other users who will be 
operating from what in essence becomes an illegitimate client 
20 device 2, only one client (legitimate client 1 or illegitimate 
client 2) can successfully log in subsequently without server 5 
invoking special action, such as causing the requesting client 
1,2 to re-execute the registration/reset phase. This 
represents a disincentive for the legitimate user to share his 
25 credentials, since his. own usage of his account will be 
negatively impacted. 

If the legitimate user's credentials are copied in a 
credentials theft, then one of the following scenarios will ^" 
svLbsequently occur: 
30 1) The legitimate client 1 logs in again before the 

attacker 3 attempts to masquerade as a legitimate user. In 
this case, the attacker 3 log-in will be alerted to. the server 
5 and consequently be subject to special action, such as 
rejection outright or granting of reduced privileges, 

\' 
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2) The attacker 3 logs in before legitimate client 1 logs- 
in again. In this case, attacker 3 can successfully masquerade 
as a legitimate user up to the time of the legitimate user's 
next log-in. On the legitimate ueer-s next log-in, server 5 
will be alerted and special action taken. This special action 
might include out-of-band communication with the legitimate 
user, investigation of the situation, and consequent shut-out . 
of attacker 3 from further validations. 

An alternative embodiment is illustrated in Figure 4. The 
method of claim 4 is identical to the method of Figure 3 
wherein acknowledgement data are used, except that steps 33 and 
34 are consolidated into steps 41 and 42. Thus, in the Figure 
4 embodiment, unlike the Figure 3 embodiment, the presentation 
of proof data by client 1 and the checking of the proof data by 
server 5 are not perf ormed prior to server 5 generating update 
data S3 and hew secret 54 in step 37. 

Step 50 of Figure 4 replaces step 41 of Figure 3. In step 

50, client 1 sends both the proof data and the acknowledgement 
data to server 5. The proof data are computed on the new 
secret 54 . The proof data could serve a double role as proof 
data and acknowledgement data. In this case, there is no need 
for acknowledgement data separate and apart from the proof 
dat8> * 

' step 51 of Figure 4 replaces step 42 of Figure 3 . In step 

51, server 5 checks both the proof data and the acknowledgement 
data, or, in the case where the proof data serve the double 
role as proof data and acknowledgement data, the proof data. 

AS stated previously, there may be legitimate use of a 
number n of different client devices 1 by a single legitimate 
user, in this case, server 5 holds current SUS's SO. and- new 
SUS's S4 for each client device 1, and considers each client, 
device 1 to be legitimate; and each client device 1. has its own 
unique SUS 50 and new SUS 54. The number n of clients 1 may be. 
restricted in accordance with local policy, in this scenario, 
SUS'S 50, 54 are respectively unique from one device 1 to the 
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■ next . The registration/reset process has to be undertaken by 
each client device 1 to establish each SUS 50. In all other 
respects, the invention is the same as described above in 
conjunction with the single client 1 embodiment, 
5 The above description is included to illustrate the 

operation of the preferred embodiments and is not meant to 
limit the scope of the invention- The scope of the invention 
iis to be limited only by the following claims. From the above 
discussion, many variations will be apparent to one skilled in 
10 the axt that would yet be encompassed by the spirit and scope ^ 
of the present invention. 
What is claimed is : 
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Claims . 

1. A method for validating a client device by a server 
device, said method comprising the steps of: 

generating a shared unpredictable secret; 
5 storing the shared unpredictable secret in the client 

device and in the server device; 
requiring the client device to prove that it holds a 
correct secret as a precondition to the server 
% device validating the client device; and 

10 replacing the shared unpredictable secret by a new 

shared unpredictable secret when the server device 
validates the client device. 

2 . The method of claim 1 wherein an initial shared 
unpredictable secret is determined in the client device and in 

15 the server device during a registration step that occurs prior 

j, to a log-in step. 

3.. The method of claim 2 wherein the registration step 
entails more checking of bona fides of the client device than 

does a log- in step. 
20 4. The method of claim 2 wherein, during the registration 

step, the client device is required to make a payment to the 
user device. 

5 . The method of claim 1 wherein the shared unpredictable 
secret is generated by a generator from the group comprising a 

25 random number generator and a pseudo-random number generator. 

6 . The method of claim 1 wherein the shared unpredictable 
secret comprises an unpredictable component and a fixed 

. component . 

7 . The method of claim 1 wherein a plurality of client 
devices desire to be validated by the server device; and 

each client device has a unique unpredictable secret 
that it shares with the server device. 

8 . The method of claim 1 wherein, following a validation 
of the client device, the server device discards the original 

35 shared unpredictable secret and stores within the server device 
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a new shared unpredictable secret that can be generated by- 
applying update data to the original shared \inpredictable 
secret . 

9, The method of claim 1 wherein: 

5 the server device sends update data to the. client 

device/ 

the client device applies the update data to the 
shared xanpredictable secret to generate a new 
secret; and 

10 the client device replaces the shared xinpredictable 

secret with the new secret. 

10, The method of claim 9 wherein: 

the server device generates the update data using a 
generator from the group comprising a reuadom 
15 number generator and a pseudo-random number 

generator; and 
the step of applying the update data to the shared 
unpredictable secret comprises computing a. one-way 
function of the coinbination of the shared 
20 unpredictable secret and the update data. 

11, The method of claim 9 wherein the client device sen4? 
acknowledgement data to the server device to confirm that the 
client device has replaced the shared unpredictable secret with 
the new secret. 

25 12. The method of claim 11 wherein, in response to the 

server device receiving the acknowledgement data from the 
client device, the server device: 

validates the client device; and 

discards the shared xrnpr edict able secret and stores 
30 within the* server device the new secret, which now 

becomes a new shared unpredictable secret. 
13. The method of claim 11 wherein: 

the client device sends to the server device proof 
data demonstrating that the client device holds a 
35 correct secret; and 
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the server device is adapted to accept from the 
client device any proof data that are generated 
from a secret that is newer than the secret for 
which the most recent acknowledgment data have 
5 been received by the server device. 

14. The method of claim 11 wherein: 

the client device sends to the server device. both the 
acknowledgment data and proof data derived from 
the new secret. 
IQ 15. The method of claim 14 wherein: 

the proof data are computed on the new secret; and 
the proof data serve also as acknowledgment data. 
\ 16. The method of claim 1 wherein: 

the client device presents proof data to the server 
15 . device, wherein the proof data are derived from a 

shared \mpredictable secret using a proof data 
generation algorithm, and the proof data do not 
divulge the shared unpredictable secret; 
the server device checks the proof data by using a 
proof data generation algorithm consistent with 
the proof data generation algorithm used by the 
client device; and 
when the server device determines that the proof data 
presented by the client device wiere not generated 
25 from the same shared unpredictable secret that is 

stored in both the client device and in the server 
device, the server device does not validate the 
client device • 

17 . The method of claim 16 wherein each proof data 
30 generation algorithm is a one-way function. 

18. A system for enabling a server device to validate a 
client device, said system comprising: 

at least one client device; 
a server device; 
i5 a shared unpredictable secret; 
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means for storing the shared unpredictable secret in 

the client device; 
means for storing the shared unpredictable secret in 
the server device; 
5 coupled to the client device and to the server 

device, means for determining whether the client 
device holds a correct secret; 
coupled to the determining means, means for allowing 
the server device to validate the client device 
10 when the client device proves that it holds a 

correct secret; and 
coupled to the client, device and to the server 
device, means for replacdlng the original shared 
unpredictable secret with a new shared. 
15 unpredictable secret when the server device 

validates the client device, 
19. A con^uter readable medium containing computer 
program instructions for enabling a server device to validate ^ 
client device,, said computer program instructions causing the 
20 execution of the following steps: 

generating a shared unpredictable secret; 

storing the shared unpredictable secret in the client 

device and in the server device; 
requiring the client device to prove that it holds a 
25 correct secret as a precondition to allowing the ^ 

client device to be validated by the server 
device; and 

replacing the shared unpredictable secret by a new 
shared unpredictable secret when the client device 
30 is validated by the server device. 
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